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Sir: 



I. 



4. 



1, Steven T. McClure, am one of the originally-named inventors of the above- 
captioned U.S. Patent Application No. 10/812,291, filed in the United States on 
March 29, 2004 (hereinafter "the present patent application"). 

EMC Corporation is the Assignee of the present patent application. I was 
employed by EMC prior to, and on the date of, the filing of the present patent 
application. 

I understand that U.S. Patent Application Pub. No. 2004/0205384 Al to Lai et al., 
filed in the United States on February 1 8, 2004, and published October 1 4, 2004, 
has been cited by the Examiner against the present patent application. 

Before February 1 8, 2004, 1 contributed to the conception and development of the 
invention set forth in the present patent application, specifically having at least the 
features described below: 

a) "A method of accessing data memory, comprising: 

writing data to a first memory location and to a second memory 
location in response to a request to write data to a memory address that 
corresponds to both locations, wherein the first and second memory 
locutions are mirrored; 

in response to a request to read data from the memory address, 
reading data from the first memory location or die second memory 
location based on load balancing; and 
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accessing data from the second memory location in response to a 
request to access data at the memory address when memory hardware 
corresponding to the first memory location has failed " 

b) "Computer software that accesses data memory, comprising: 

executable code that writes data to a first memory location and to a 
second memory location in response to a request to write data to a 
memory address that corresponds to both locations, wherein the first and 
second memory locations are mirrored; 

executable code that reads data from the first memory location or 
the second memory location based on load balancing in response to a 
request to read data from the memory address; and 

executable code that accesses data from the second memory 
location in response to a request to access data at the memory address 
when memory hardware corresponding to the first memory location has 
failed." 

c) "A data storage device, comprising: 

a plurality of disk drives; 

an internal volatile memory; and 

a plurality of directors coupled to the memory, wherein some of 
the directors are coupled to the disk drives and some of the directors allow 
external access to the data storage device and wherein each of the directors 
access the memory by writing data to a first memory location and to a 
second memory location in response to a request to write data to a 
memory address that corresponds to both locations, wherein the first and 
second memory locations arc mirrored, in response to a request to read 
data from the memory address, the directors read data from the first 
memory location or the second memory location based on load balancing, 
and the directors access data from the second memory location in response 
to a request to access data at the memory address when memory hardware 
corresponding to the first memory location has failed." 

5. In support thereof, attached hereto as Exhibit A is a copy of e-mail exchanges by 
and among the inventors, including myself, concerning development of the 
subject matter of the present patent application. The dates of these documents 
have been redacted; however, all of the redacted dates are from a time prior to 
February 18, 2004. 

6. Further, attached hereto as Exhibit B is a copy of e-mail exchanges by and among 
the inventors, including myself, concerning development of the subject matter of 
the present patent application. The dates of these documents have been redacted; 
however, all of the redacted dates are from a time between February 18, 2004, and 
the March 29, 2004, filing date of the present patent application. 
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7. All of the work that is reflected in the contents of Exhibits A and B was 
performed in the US or other WTO country. 

8. Furthermore, during the period between February 1 8, 2004, and the March 29, 
2004, filing date of the present patent application, I and the other inventors 
received communications from, and I responded to, EMC's outside patent counsel 
concerning drafts of the present patent application that were being prepared by the 
outside patent counsel. 

9. To the best of my knowledge and belief, T and the other inventors were diligent 
from a time prior to February 18, 2004, until the invention was constructively 
reduced to practice by filing the present patent application on March 29, 2004, 

1 0. I hereby declare that all statements made herein of my own knowledge are 

true and that all statements made on information and belief are believed to be true; 
and further that these statements are made with knowledge that willful false 
statements and the like so made are punishable by fine or imprisonment, or both, 
under Section 1001 of Title 1 8 of the United States Code and that such willful 
false statements may jeopardize the validity of the above-captioned Application 
for Patent or any patent issuing thereon. 



Respectfully submitted, 





Steven T. McClure 
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Subject:RE: Some more SW docs 
Date:: 

From:rosner, tim <rosner_tim@emc.com> 

To:decrescenzo, bob <decrescenzoJpob@emc.com> , mcclure, steve (Calendar Only) 
<mcclure_ste ve@.eng . emc . com> 

We are obligated to send them either design specs or a usage manual of how 
we plan to implement the HW. • 



> Original Message 

> From: decrescenzo, bob 

> Sent: 

> To: rosner, tim; mcclure, steve (Calendar Only) 



> Subject: RE: Some more SW docs 
> 

> Tim, 
> 

> 

> Steve & myself discussed this and the last 2 items on his bulletized 

> list should be added to the functional spec. Steve is going to talk to 

> Jerry about getting them added. The other items will be addressed in the 

> design spec. The design spec should be done some time by the end of the 

> month. When it's complete and signed off we can distribute a copy to the 

> HW group. 
> 

>^Are we going to send them all our design specs? This is a general 

> question about all designs. 
> 

> 
> 



> Original Message 

> From: rosner, .tim 

> Sent: 

> To: decrescenzo, bob; mcclure, steve (Calendar Only) 

> Subject: FW: Some more SW docs 
> 

> FYI regarding mirrored memory. 
> 

> Comments from the HW group. 
> 

> Original Message 

> From: wilson, paul (HW ENG) 

> Sent : . 

> To: rosner, tim 
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> Subject: FW: Some more SW docs 
> 

> Tim - 

> 

> Some questions that came up when reviewing the Usage Guide" 

> documents we received from uCode. I have attached them to make sure you 

> know which documents I'm talking about. This was related to the mirrored 

> memory programmers guide 
> 

> Should these be addressed here? 

> * Description of implementation of Atomic Operations 

> (under SW control) . 

> * Description of FMI : assertion, detection, reporting 

> mechanism to multiple directors, expected response, etc. 

> * Error thresholds that are used to determine when a 

> memory board fails 

> * Conditions that may be seen when pulling a memory 

> board; 

> * Configuration impacts: eg, 3 32GB & 1 16GB. 16GB 

> fails, replace with 32GB. 
> 

> 

> « Message: Mirrored Memory SRS » « Message: Mirrored 

> Memory Functional Spec » 
> 

> Are there other documents covering these issues? Should 

> these be in these documents? 
> 

> Thanks, Paul 
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Subject:RE: Mirrored Memory External Review 
Date: r 

From:araskiewicz, susan <^askiewicz_susan@,emcxom> 

To: cartmell, jerry <cartmellJerry@emc.com> . decrescenzo, bob <decrescenzo bob@emc.com> , 

rosner, tim <rosner_tim@,emc.com> 
CC:mcclure, Steven <smcclure@,emc.com> 



Great I will set it up. Who should be included in the meeting? 

Thanks 
Susan 



> Original Message 

> From: cartmell, jerry 

> Sent: 

> To: decrescenzo, bob; araskiewicz, susan; rosner, tim 

> Cc: mcclure, steven 



> Subject: RE: Mirrored Memory External Review 
> 

> We can do a external review on the FS on ; cs . ) 

> 

> Jerry 
> 

> Original Message 

> From: decrescenzo, bob 

> Sent: 

> To: araskiewicz, susan; rosner, tim; cartmell, jerry . 

> Cc: mcclure, steven 

> Subject: RE: Mirrored Memory External Review 
> 

> I believe the fuctional spec is in good shape, but this is up to 

> Jerry. He should be able to give you the state of the functional spec and 

> also when he would be ready for an external review. 
> 

> — Bob 



> — : Original Message 

> From: araskiewicz> susan 

> Sent: : 

> To: decrescenzo, bob; rosner, tim; cartmell, jerry 

> Subject: . RE: Mirrored Memory External Review 
> 

> OK, so why don't I plan on scheduling an External Functional 



> Review; 
> 
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> Bob does the document need td be revised or is it ready to 

> be sent- out for review before the external meeting. I can target setting 

> the meeting up for next week if that works. 
> 

> Tim who needs to be on the external distribution list? 
> 

> Thanks 

> Susan 
> 

> Original Message 

> From: • decrescenzo, bob 

> Sent: 

> To: araskiewicz, susan; rosner, tim; cartmell, 

> jerry 

> Subject: RE: Mirrored Memory External Review 
> 

> Yes. We only had an internal review. There has 

> been nothing done externally. 

> 

> Original Message 

> From: araskiewicz, susan 

> Sent: j 

> To: decrescenzo, bob; rosner, tim; cartmell, 

> jerry 

> Subject: RE: Mirrored Memory External Review 
> 

> Bob, I was under the impression you already had the 

> functional review. Was it just an internal review? 
> 

> Thanks 

> Susan 
> 

> Original Message- 

> From: , decrescenzo, bob 

> Sent: 

> To: rosner, tim; araskiewicz, susan; cartmell, 

> jerry 

> Subject: RE: Mirrored Memory External Review 
> 

> I think they will get this from a functional review. 

> I don't think anyone can get anything out of design review without having 



> a functional review first. The functional review would explain "what" we 

> are going to be doing. The design review explains "how" we did it . 

> internally in the code. If they don't thoroughly know and understand the 

> "what" then the "how" is going to be meaningless. 



> 

> —Bob 
> 

> Original Message 

> From: rosner, tim 

> Sent: 

> To: decrescenzo, bob; araskiewicz, susan; 

> cartmell, jerry 

> Subject: • RE: Mirrored Memory External Review 
> 

> Bob, 
> 

> I understand your point, however if you don't mind I 



> would like to continue with the external review. Trust me I will not 

> allow any external group influence our design. 
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> The reason why I want external involvement is 

> because I want to have them understand the extensive work your group is . 

> going threw and that it's not just .a simple change. . 
> 

> TR 
> 

> Original Message 

> -. From: decrescenzo, bob 

> Sent : • 

> To: araskiewicz, susan; cartmell, jerry 

> Cc: rosner, tim 

> Subject: RE: Mirrored Memory External Review 
> 

> Susan, 
> 

> I don't know if we want to have an external 



> design review. The only information that external groups should care 

> about is in the functional spec. We may want to have an external 

> functional review. I don't think product management, marketing, etc. 

> really care if we are using separate internal threads to do fail-over or 

> if we do this fail-over inside existing threads. This is the details in . 

> the design spec. They really only care about how the feature going to 

> "function". If design questions come up we can explain how. we are going 

> to implement something, but I don't think this should be the focus to 

> external groups. 
> 

> We don't want to give external groups the ability to 

> direct/change our designs. We want their feedback on how the feature is 

> going to function to. make sure it's in alignment with what they expected. 

> I don't think this applies to our own internal designs. 



> 

> Tim, what do you think? 
> 

> 
> 

> Original Message 

> From: araskiewicz, susan 

> Sent: r ' 

> To: cartmell, jerry • 

> Cc: decrescenzo, bob 

> Subject: Mirrored Memory External Review 
> 

> Hi Jerry, Congratulation on a very successful 

> Internal Design Review for Mirrored Memory. 

> 

> Below are my meeting minutes from the Mirrored 



> Memory Internal Design Review. 
> 

> 
> 

> Action Items: 
> 

.> Need to come to an agreement with Vault. (Jerry) 

> 

> Wayne Sylvia will send question to Jerry. (Wayne) 
> 

> Discuss Special Command with Haim (Jerry) 
> 

> 
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> Discussions: 

> 

> You still want- SymWin Scripts 
> 

> Scott Gordon will write a utility (Syscall) to light 

> the light (LED) 

> 
> 

> When would you like to schedule and External Review. 

> I want to give you enough time to complete the action items. 
> 

> Thanks 

> Susan 



